In a typical application server, for example the WebLogic Server product from BEA systems, Inc., for an EJB to be deployed in the server, the EJB Compiler must be invoked on the ejb-jar file containing the EJB prior to deployment. For each EJB in the ejb-jar file, the EJB Compiler is responsible for validating the EJB, generating wrapper classes for the EJB, compiling the generated wrapper classes and invoking the RMI Compiler when necessary. This can be a time consuming process, on the order of several seconds per EJB. For an ejb-jar file with a large number of EJBs, the combined time can be significant.
To make matters worse, the EJB Compiler usually needs to be run each time the ejb-jar file is updated. An ejb-jar file is typically updated several times as it is developed. Compounding the issue further is the fact that the EJB Compiler is often invoked via a script, which doesn't typically have logic to determine whether the EJB Compiler actually needs to be invoked or not. This means the script invokes the EJB Compiler even when it doesn't need to, wasting valuable time.
The EJB Compiler also needs to be run after the server is upgraded, since the classes generated by the EJB Compiler may be incompatible with the new server code. If, after upgrading to a new server version, the user forgets to run the EJB Compiler before deploying the EJB, unexpected errors can result.
Another problem is that users may forget to run the EJB Compiler on an EJB after updating it. This can also lead to unexpected errors when the EJB is deployed since the classes generated by the EJB Compiler may no longer be compatible with the EJB.